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JUSTIFICATION 

At present* creation of graphic structures for use with the 
Multics Graphic System must be performed by coding PL/I proce- 
dures which create* edit, and display these structures on an in- 
dividual basis. The program must be re-edited and recompiled to 
altar the structure created* This is especially teuious while 
picture descriptions are still in the debugging stage. It is un- 
reasonable to expect users of the graphic system to code special- 
ized routines to create graphic structures every time a new 
structure is desired. 

PRECEDENTS 

Users of the Version 1 Graphic System had available to them 
an Author-Maintained program, pix_edit» which functioned as an 
interactive picture editor. With it* users could enter picture 
descri pt ions , view the results immediately* and perforn, limited 
alterations of their pictures. As pix_edit was not designed to 
be a generalized editor, it lacked all but the most rudimentary 
means of altering picture elements (i.e. retyping the entire sub- 
construct.) Users found that it was usually easier to use a text 
editor to place the description into a file* call pix_edit to 
parse and display the construct, and re-enter the editor to make 
alterations. The author of pix_edit (Ken PogranJ later proposes 
a graphic editor with extended features in an RFC. The extended 
editor was never implemented. 

PROPOSAL 

The attached documentation describes a graphic editor very 
much I ike that proposed in the RFC mentioned. Because of im- 
oroved structure editing capabilities in the Version ? 
graph ic_mani pu I a t or_, it incorporates several new features whirh 
were not possible to perform using the Version l gsm_ package. 
The functionality provided by this interactive tool would be in- 
valuable to both the casual user of graphics and to the imp I omen - 
tor of extensive graphic; applications. 

Comments and suggestions nay be mailed to Ta var es • Jlu I t ics on 
System 1 ( Phoeni . 
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The graphic_edi tor is an interactive tool which may be used 
to create and eait graphic structures* It is caoable of storing 
these structures into, and retrieving them from , permanent graph- 
ic segments (PGS's). 

graoh ic_edi tor Cseg.il Iseg2l ••• Csegn] 

1) segl (ootional) is a pathname specifying a segment to be 
read into the graphic editor. This segment m?y contain 
a list of editor commands or assignments* in the same 
format as they might have been typed into the editor 
interactively. The segments will be interpreted by the 
editor in the order specified. 



If any errors occur while reading any segment specified on 
the command line, processing of that file will cease. 

When gr aohic_ed i tor is ready . to receive input frop the 
user's terminal, it replies with "Edit,", The user may then 
begin to issue requests. 



Requests fall into two categories* commands and assign- 
ments. In general, commands may be terminated witn either a 
semicolon {"*") or a newline. Assignments (due to their ability 
to be quite lengthy) may be term i na tea only with a semicolon. 
Sometimes one of more of the arguments of a command may be an 
assignment. In these cases, only the semicolon is accepted as a 
terminator. 

Comments which are enclosed by 'V* ... may be inter- 

spersed with any input lines. 



Symbo I s 

Symbols ir- the graph ic_ed i tor are alphanumeric representa- 
tions of node values. A node number is a "receipt" which the 
graphic system returns whenever it is asked to create some graph- 
ic element. (For a more complete description of node values, 
refer to Section l of the Graphics Users* Supplement.) Symbols 
have a value wnich consists of exactly one such node value. 

Symbols may be divided into three classes! the system sym- 
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hoi, which is predefined and represents a primitive operation or 
element? the user symbol* which is, defined by the user at f ,onip 
time with an assignment; and tne macro, which is defined by the 
user, but takes "arguments*', and has no permanent value of its 
own . 

System symbols h^ve no permanent value. They take one or 
more arguments, either implied or explicit. The use of a system 
symbol represents a reauest that a new element be created. The 
node value returned from that creation is then used in any subse- 
quent operation of that particular expression. 

Examples of system symbol expressions are: 

vector i? Ik a vector of length <l?» 0) 



Axolotl" uc 



a text string containing the string 
"Axolotl", aligned by the upper center 
ed ge . 



arr^y (a,o,c) an array containing the nodes represent- 
ed by user symbols a, b, ana c. (See 
TuoleSf be I ow • ) 



I i n do 1 1 ed 



A mode element for dotted lines. 



A list of system symbols and descriptions of their use may 
be found at the end of the document. 



User symbols may be uo to 32 characters in length, and may 
consist of any combination of upper-case and lower-case alphabet- 
ics, numerals, and the underscore (**_"), provided that the first 
character is non-numeric. System symbols and commands are con- 
sidered "reserved words", and may not also be used as user sym- 
Pols. Attempts to define commands as symbols will result in 
ill-formed execution of those commands. 

Fxamoles of user symbols are! 

f oo 

Fr on t_cor ch 
bo!t_23w9 

User symbols are stored in the graphic symbol table of the work- 
ing graphic segment (WGS) . They are transferred to and from 
f>GS # s whenever the "save", "use", "put", and "get" system com- 
mands are used. (For a more complete explanation of graphic sym- 
bols, see Section l of the Graphics Users* Supplement.) 
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Macros are user symbols which take arguments like system 
symbols. Whenever a macro expression is evaluated, the arguments 
supplied are substituted for the dummy arguments with which the 
macro was defined. Macros must be defined by macro assignments. 
For exarcpl el 

macro box x y = v/ec x G, vec 0 y, vec -x 0* vec Q -yj 

defines a macro named "box" with dummy arguments "x" and "y". 
The references 

box 10 33 

represents a rectangle iQ units in x and 30 urits in y, and is 
exactly equivalent to the expression! 

vec 10 0* vec 0 30* vec -lO 0, vec 0 -30 

Macro names are stored in the graphic symbol table of the WGS, 
and may be transferred to an 1 from PGS • s with *he "save", "use", 
"put", and "get" commands. 



Tuples 

A tuple is simply a group of one or more values* Every com- 
plete symbol (i.e. a user symbol, or a macro or system symbol 
with its arguments) is a tuple in itself (a one-tuple). A tuple 
of more than one element may be expressed as its elements separa- 
ted by commas, e.g.: 

a, b, b, vec 13 k 3* intensity if xxx 

This is a tuple of 6 elements. 

tuole which has mo«~e than one element represents more thin 
one graphic entity. Therefore, it cannot have one node value. 
To convert a tuple to a single graphic entity, two system symbols 
are available? array, and list. These two "functions" gather the 
elements of the tuole into a graphic array, or a graphic list 
(respectively). (^or a more complete explanation of graphic ar- 
rays and lists, see Section 1 of the Graphics Users* Supplement.) 
The creation of this array or list produces a node v<j I ue , which 
may be assigned to a user symbol, or may be used without assign- 
ment in some larger expression. For example: 

one_array = array (a, b, c, d, b) * 
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is an assignment which creates a graphic array with the elements 
(a, b, Ct d, and b) , and assigns to "one_array" the value of this 
I ist . 



assignments 

An assignment is an ooeration which extracts the value of 
one tuple and assigns it to another tuple* The assignment opera- 
tor is the infix **=" sign. 

The simple assignment: 

foo = bar? 

specifies that the the value of "foo" is to become the symbol 
"bar". An important point to Keep in mind is that this does not 
mean that "foo" ar 1 "oar" both refer to the identical piece of 
graphic structure, father, "foo" cont a ins "bar", and (of course) 
indirectly also contains the entire structure contained by "bar", 
(It is possible to assign the value of a symbol to another sym- 
bol* rather than assigning one symbol to another? this operation 
will be discussed in the section describing qualified expres- 
sions.) If "foo" is undefined at the time of assignment, it will 
be created. If it had a previous value, that value will be re- 
placed. Any other graphic structures which referenced "foo** will 
still refer to it, but *ili now contain (indirectly) its new 
va I ue. 

In general, only tuoles of like dimensionality (i.e. having 
the same number of elements) may be assigned to each other. Fo*~ 
ex amp I e : 

a, b * c = d ♦ e , f* 
x = arr av ( p , q, r ) * 

are both valid assignments. However, 

one, two = three, four, five* 

is not 3 valii assignment. 

Two exceotions exist to this rule: First, if the object to 
the right of the assignment operator is a one-tuple, it may al- 
ways be "promoted" into the d i mens i ona I t y of the object to the 
left of tne assignment operator. For example: 

a , b, c = d ! 
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is ■?qutv3lent to 

a=o?b = ci;c = d; 

The second exception is that if the object to the 

assignment operator is a one-tuole, and the object to 

of the assiqnment ooerator is not a one-tuple, then 

operator is assumed. For instance* the assignments? 

a = b , c t d ? 
a = array < b, c , d) ? 

are equivalent. Note that the promotion facility and the impli- 
cit-array operator can never be used simultaneously. This fea- 
ture disallows statements such as: 

one, two = three, four, five; 

which more probably represents a user error than a useful state- 
ment. 



Assignments also have values. The value of an assignment is 
the value of the tuple into which the assignment is done. For 
example, the value of 

f oo = bar ; 

is the new value of "too". This feature allows nested assign- 
ments* as in the following example: 

oic = some_setpos, (line = vector lOOl? 

This is equivalent to: 

I ine = vector 100 ? 

nic = some_.se tpos , line? 

Note the us? of the parentheses for precedence definition. The 
oarentheses in the expression are necessary since tuple formation 
is a "stronger" operation than assignment. If the exoression ha:1 
been written as* 

pic ■= some_setpos, line = vector lOO? 

it would have been oerformed as the operations: 

some_setnos, line = vector 1 0 0 ? /* a promotion */ 

pic - sooie_sf i tpo >, line? /* an implicit array */ 



left of the 
the r i gh t 
the "array" 
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Qualified Expressions 

Tt is possible to refer to any element (or tuple of ele- 
ments) of a symbol which represents an array or list by the use 
of qualified expression. The simplest qualified expression con- 
sists of a symbol i followed by a period. This represents "the 
value of". In our first example* 

foo = bar: 

we assigned "bar" as the value of "foo". The relationship of 
"foo" to "bar" was a superior/inferior* or father/son relation- 
ship. Ift instead, we say 

foo = bar,; 

we are assigning the y.aiue of "bar" to "foo". This makes both 
"foo" and "bar" refer to the identical oiece of graphic struc- 
ture. The symbols now have a "brother" relationship. 

Successive trailing periods denote further levels of evalua- 
tion. Assume the following assignmentst 

box = vec 10* vec 0 10* vec -10» vec 0 "10? 

a = b = c = d = box? 

The following relations hold on these symbols? (Read "5" as "is 
eoui va I er t to") 

a • = b 

a • . 1 b . = c 

a « . • 5 b . • £ c • £ d 

o • • • • £ b • • t £ c • • £ d • — box 

The assignment 

a ... - n j I I * 

actual ly assigns "null" to "d". 

Additional types of qualified expressions make it possible 
to refer to elements of lists. The element desired is denoted by 
an integer following the appropriate levels of qualification. 
For example* 

box.? 
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is the second element of "box" (vector C iQ). Tuples of contigu- 
ous elements may be specified by using a range expression, which 
consists of two integers (represent ini the first md last element 
desired) separated by a colon (":"). For example, 

bottoml ess_box = array (box.2:**)* 

will create a symbol which contains an array made up of all ele- 
ments of "box" except the first. 

The star ("*'*) has 3 special meaning in a qualified expres- 
sion. If used by itself, e.g. "box.*", it refers to a tuple rnaae 
up of all the element of "box". It may also be used as the last 
part of a range expression, e.g. "box.??*", which refers to a 
tuple made up of all the elements of "box" from the secord to the 
last. The assignment 

bo t torn! ess_box = array (box.?:*) 

is equivalent to the example above. Mote that if a star occurrs 
in a qualified expression 1 it must be the I as t character. It may 
neither be followed by the second component of a range expression 
(e.g. "box.*: 3") nor by further levels of qualification (e.g. 
"box.*. 1") . 

Because a user may not always know exactly how many levels 
of symbol indirection exist between the symbol name he is working 
with and the arrays or lists with which he desires to work, any 
reference to an element (or range of elements) of a list found in 
a qualified expression will cause the evaluator to skip any num- 
ber of levels of symbol indirection. Using one of our previous 
examples to elucidate, this means that 

a.t = a ..... 1 £ box.l 

This frees the user of typing in long, and possibly inaccurate, 
strings of periods? but allows the user w*o wants to maintain 
fine control of his indirect symbol structuring to do precisely 
that . 

Certain qualified expressions may have different meanings on 
the left side of an assignment than they do on the right side. 
This is particularly important to note when using nested assign- 
ments. In particular, qualified expressions which evaluate to an 
element of an array or list, or to a tuole pf such elements, have 
different meanings in these two contexts. If such an expression 
occurs on the right side of an assignment, its value consists of 
references to thf values of the elements which make up the list. 
A previous exaruplr ( "bo 1 1 om I ess_box" ) showed how this usage is 
interpreted. Or the left side of the assignment, however, the 
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expression denotes element replacement. Eor instance, assume the 
following assignments: 

box = vec 10, vec G 10, vec -10, vec 0 -1C? 
elem = bo x . 3 * 
box. 3 = shift -ic: 

The first assignment defines "box". The second assignment causes 
"elem" to refer to the same oi ece of graphic structure which is 
the third element of box. The third assignment changes the "top 
of the dox" from a visible vector to an invisible shift by rede- 
fining the third element of "box" to be a shift of equal magni- 
tude. This does no.± change the valup of "elem". It simplv 
breaks the association between the list "box" and the construct 
which was its third element. It the actual changing of that con- 
struct were desired, the third assignment of the above example 
could be replaced with 

box . 3 . = sh i f t -in; 

This assignment would in fact change the value of elem. A 
side-effect of this property is that the expressions "symbol. n" 
and "symbol. n." are equivalent on the right side of an assign- 
ment, but a<~e not equivalent on the left side. 



Node Constants 

It is possible for node values to exist in the WGS without 
being assigned to any symbol. For instance, a user program could 
be called from inside the editor to construct a oar t icu I ar I y in- 
tricate "canned" graphic structure which may be inefficient or 
difficult to construct by hand. The program could print the num- 
ber of the top-level node in the structure, so that the user 
could "nick it up" by assigning a name to it. The number of this 
node may be typed in, o receded by the character "#". This is j 
"node constant". 

Tor example: if the node constant "#123^+5" appears as such 
an output, ^nd it is wished to assign to this node the name 
"orphan", the assignment: 

orphan = ii±??A^' 

may be used. 

Octal node values may he expressed directly as node con- 
stants without user conversion by immediately following the "#" 
with the lowercase letter "o", e.g. "#ol<+<+" is equivalent to 
"#100" . 
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Although nod? constants and qualified expressions based on 
node constants are allowed on the left-hand side of assignment 
statements* their use is strongly discouraged. 



Commands ■ 

Following is a list of editor commands. Arguments enclosed 
in angle backets ("< ••• >") denote necessary arguments. Argu- 
ments enclosed in square brackets ("t ••• 1") denote optional 
arguments. Each command whose argument is signified by <exprn> 
will accept single elements* tuples* assignments, or any combina- 
tion of these as its argument. For example? 



display pic = array (house, street* parked_c ars ) * 
serves the dual purpose of defining "pic" and diso laying it. 



> > display <exprn> 

di <excrn> 

causes the screen to be erased and the graphic structure speci- 
fied to be displayed. If the argument is a tuole* no erase is 
performed between each element of the tuple. 



> > list [options! 

Is [options] 

will list selected symbol tables. Any number of options may be 
specified. The following options are allowed; 



-commands -com list the editor commands and their abbreviations. 

-system -sys list the available system symbols and their ab 
breviat ions. 

-macros -mc list the defined macros. 

-symbols -sym list the user symbols. 

-all -a I is t a II of the above • 

If no options are given* "-symbols" is assumed. 



> > execute <command_l ine> 

exec <command_l ire> 
causes the <command_l ine> to be passed to the command processor. 
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> > show <exorn> 

causes an abbreviated descriotion of the tuple <exprn> to be 
printed to the user's terminal. If the value represents a termi- 
nal graphic element, its contents will be printed. If it repre- 
sents a non- term ina I element, it will be described and the number 
of its elements oiven, 

> > replay <exprn> 

like show, except that the entire graphic subtree inferior to the 
chosen node is described in assignment notation, along with nes- 
ted assignments where appropriate. This command allows a user to 
"replay" a jraor ic structure in a form acceptable as inout to the 
graph ic_ed it or • 

> > remove <svmboli> (symbol?! ••• (symbolnj 

causes those elements named to be removed from the table of known 
user symbols. The symbol in the WGS is also deleted, and all 
references to it will be transformed into direct references to 
whatever contents it possessed. 



> > use [pathname] 

causes the permanent graohic segment (PGS) soecified by [path- 
name] to be loaded into the WGS. This allows the editor to use a 
previously-constructed set of graphic structures. If [pathname] 
is not supplied, graph ic_edi tor will use the pathname which was 
last supplied to a "use" or "save" command. If no such pathname 
exists, an error will occur. If an error occurs during the exe- 
cution of i "use" command, the "last pathname" will be deliber- 
ately forgotten. 



> > save [patrnamel 

causes the conterts of the WGS to be saved in a PGS specified by 
[pathname]. If [pathname] is not supplied, graph ic_edi tor dill 
use the pathname which was last supplied to a "use" or "save" 
command. If no such pathname exists, an error will occur. If an 
error occurs during the execution of a "save" command, the "last 
oathname" will be deliberately forgotten. 



>---> g^t [mode] [(pathname)] <sym> (sym?J ... [symn] 

gets the structures <syml> ... (symnj from the PGS specified by 
[ (pathname) 1 • (This notation means that "pathname", if it is 
given, must be within parentheses.) The (mode] argument deter- 
mines what action is taken on attempts to redefine an existing 
name i 
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-safe leave the old symbol as is and print an error message, 

-force redefine the symbol and all subsidiary symbols, 
-reo I ace_on I y 

-rpo redefine the symbol. If suosidiary symbols are dupli- 

cated in the WGS, use the copies in the WGS. For any 
subsidiary symbols not so duplicated* create null 
(empty) symbols, 

-reo I ace_a I I 

-rpa redefine the symbol. If subsidiary symbols are dupli- 

cated in the WGS, use the copies in the WGS. For any 

subsidiary symbols which do not exist in thfc V<GS, us? 
the ones in the PGS. 

If [mode] is not specif ied, '"-safe*" will be assumed* The [model 
and C (pathname) 3 arguments, if present, may occur in either 
order, but must precede any symbol names. 



> > put [model [(pathname) 1 <symi> Csym?] ... [symnl 

stores the structures <syml> . .. [symnl into the PGS specified by 
[(pathname)]. The (model argument determines what action is 
taKen on attempts to redefine an existing name: 

-safe leave the old symbol as is and print an error message. 



- f or ce 



redefine the symbol and all subsidiary symools 



-rep I ace_onl y 

-rpo redefine the symbol- 

cated in tne PGS* 
subsidiary symbols 
(emoty) symbols. 



If subsidiary symbols are 



use the copies in the 
not so duplicated, 



PG 



dup I i - 

For any 



cr ea te nu I I 



-reolace_all 

-roa redefine the symbol. If subsidiary symbols are 

cated in the PGS, use the copies in the PGS. 
subsidiary symbols which do not exist in the PGS, 
the ones in the WGS. 



duo I i - 

For any 
use 



If (model is not specified, "-safe" will be assumed, 
sible order of the arguments is the same as for "get* 



The permis- 



> > real <pathn^me> 

causes the file specified 
set of editor commands. *\ny 
will switch the input source 



by <oathname> to be interpreted as i 
"read" command encountered in a file 
to the specified file. When the 
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commands in the specified file have been exhausted* control will 
return to the user's terminal, or to the original file issuinj 
the "read". Frrors encountered while reading from a sejnient wiii 
cause control to be immediately returned to the user's terminal. 



> > quit 

is used to exit from the editor. 
> rest ar t 

will re-initial i z e the editor, the working graohic segment, and 
all associated symbol tables. Anv remaining command line, as 
well as any file "reads" pending, will be flushed without execu- 
tion. The state of the editor after a "restart" is the same as 
the state of the editor when it is first invoked. 



> > help 

directs the user t 0 relevant documentation. 



> > macro <name> E argil ... [argoJ = <exprn> 

macro show <namel> ... [ name n 1 

macro reolav <namel> ••• tnamen] 
The first form defines a macro with name <nan:e>, and arguments 
[argil ... CargnJ. The other forms do for macros what "show" and 
"replay" do for symbols. 



> > input <symbol> I de vi ce__name 1 

requests that a "what" input be requested from device 
[ device_name ] . The inout will be collected* interpreted, made 
into a graohic structure, and assigned to symbol <symbol>. This 
feature is not yet implemented. 



Defined System Symbols 



Positional Elements 

AM positional elements take arguments of the form "x y z". 
If any of these arguments are not supplied, it will be assumed to 
be zero. It is possible to supply no arguments, only "x", 
only "x y" , or all of "x y 7". No other combinations (e.g. 
"x z") are parsable. 



(c) Cooyr ight t97f+, Honeywell Information Systems Inc. 



MPM GRAPHIC USERS' SUPPLEMENT 



graph i c_ed i tor 



Page 13 



> > setposition (sps) 

setpoint (spt) 

vector (vecJ 

shirt (sft) 

point (pntl 



Modal Elements 

> > intensity (int) 

argument: Integer, Q through 7, or "off" (Q)* "on" (7), or "full 
(7L 

> > I ine type I I in) 

argument: Integer* l through 5, yr: 

"sol id" (D 

"dashed" (2) 

"dotted" (3) 

"dash_dotte<1" (4) 

"lonq_dashed" (5) 

> > blink (blk) 

arguments mav be any from the following correspondence list: 

"steady" Q 

"bl ink i ng" l 

> > sensitivity (snsl 

Arguments may be any from the following correspondence listt 

"insensitive" 0 
"sensitive" l 



Mapo ing E I emen ts 

> > rotation (rot) 

Arguments: "x_rotation y_rotation z_rotation" in floating or in- 
teger degrees. 

> > seal ing (scl ) 

Arguments: "x_scale y_sca!e z_scale" in integer or floating nota- 
tion. 



ii see 1 I ^neous Elements 
> > nu I I 

No arguments. This element represents the "zero node". It is a 
placeholder, or a graphic no-op. 

> > text "string" toositionj 
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"s tr ina" 
The second form of 
optional arquient 
(For a more corrplet 



[ pos i t i on ] 

th^ text string is implicitly understood. The 
[position] specifies the string alignment, 
explanation of string alignments, refer to 



Sect ion 



1 of the Graphics Users* Supplement.) Any character nny 
appear within the string. If it is desired for a auote to appear 
as par* - of the string, it may oe doubled, as in ^L/I. The 

integer or a string* 



merit may be either an 
correspondence list? 



in 
f rem 



the 



argu- 
f o I lowing 



uop* 3 r_ J e f t 

uooer_center 

uooer_r ight 

left 

center 

ri ght 

I ower__ left 
I o wer_cen ter 
I ower_r ight 



ul 
uc 
ur 
I 

c 
r 
I I 
Ic 
Ir 



>-.-> d^tablocK <element> 

data <element> 

a datablock contiining the element <e!ement>. This ele- 
be of a form acceptable as a symbol name, or numeric* or 
enclosec in quotes. It may not be a break character 
("5"i etc.) unless enclosed in quotes. Oatablocks may be 

used to hold information relevant to the structure, within the 
structure itself. (For a more complete explanation of data- 
blockSt refer to Section 1 of the Graphics Users' Supplement.) 



creates 
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a string 



Note! No oyramic ooerations are presently defined for the 
graph i c_ed i tor . 



Copyright l3 7 <+» Honeywell Information Systems Inc 



(FHJ) 



